The Score That Stops The Loop Is Judged By A Model That Cannot See The Work

This is the most technically accurate card this page has published. Six parts, each naming a real command: /init, /goal, /agents, /memory, /schedule. The four-era framing — Prompt, Context, Harness, Loop — is a genuinely useful way to think about what changed. And part two states the central idea better than most documentation does:

“No finish line, no loop. The score is the off-switch.”

That is exactly right, and it is why this piece is about one thing only: the card’s example off-switch is a 95 on your rubric, and it is worth knowing who awards that 95.

Who awards the 95

The card’s part-two prompt is /goal Score it on my rubric, don’t stop until 95. That command exists and does roughly what the card says: it sets a completion condition and Claude keeps working until the condition holds. The part the card does not describe is the evaluator.

“After each turn, a model checks whether the condition holds… /goal adds a separate evaluator that checks your condition after every turn, so completion is decided by a fresh model rather than the one doing the work.”

“Claude Code sends the condition and the conversation so far to your configured small fast model.”

“The evaluator judges your condition against what Claude has surfaced in the conversation. It doesn’t run commands or read files independently, so write the condition as something Claude’s own output can demonstrate.”

“The evaluator runs on whichever provider your session is configured for. It does not call tools, so it can only judge what Claude has already surfaced in the conversation.”

So the card is right that it never marks its own homework — the evaluator is a separate model, which is the correct design. But three things follow that change how you write the condition.

Which conditions survive this, and which do not

The documentation is unusually direct about what makes a good condition. It asks for “one measurable end state”, “a stated check” — how Claude should prove it — and the constraints that must hold on the way. Its own example is /goal all tests in test/auth pass and the lint step is clean, and it explains why that works: “Claude runs the tests and the result appears in the transcript for the evaluator to read.”

Line up the card’s example against that standard and the gap is clear.

The fix is small and it is the card’s own structure done properly. Make the rubric produce something the transcript can show. Instead of “score it 95”, have the QA agent of part four write its score and its reasons into the conversation, criterion by criterion — then the evaluator in part two has something real to read, and so do you. A number with five named reasons under it is a different object from a number on its own.

The card is halfway there already. Part four is LLM-as-judge, correctly named, with the right instinct printed on it: “It never marks its own homework.” All that is missing is the instruction to show its working.

And nothing on the card bounds the loop

Part six takes the whole thing and schedules it: “Wrap the whole loop in a Routine that runs in the cloud with your laptop closed… Set it once, walk away. It runs while you sleep.” The prompt is /schedule Run my loop weekdays at 7am.

So an unbounded condition, judged by a model that cannot inspect the artefact, now runs unattended. The documentation has a one-line answer for this and the card does not mention it:

“To bound how long a goal runs, include a turn or time clause in the condition, such as or stop after 20 turns. Claude reports progress against that clause each turn and the evaluator judges it from the conversation.”

Eight words at the end of the condition. In fairness, three real safety valves exist underneath: the evaluator can return Impossible and clear the goal; Claude Code “stops the loop, prints a warning, and returns control to you” if several turns pass with no tool use; and a goal pauses rather than spinning when it hits a usage limit. None of those is a budget. Write the clause.

The quote in the caption, checked

The post carries a named attribution: “Boris Cherny, who built Claude Code: ‘I don’t prompt Claude anymore. My job is to write loops.’” We went looking for the source, because a direct quotation in quotation marks is a claim like any other.

The attribution holds up and the wording is approximate. The line is widely circulated and consistently attributed to Boris Cherny at Anthropic, and multiple independent reposts carry it. But the transcriptions differ — the most-repeated longer version runs “I don’t prompt Claude anymore. I have loops that are running. My job is to write loops” — and sources disagree about which interview or talk it comes from. We could not reach a primary recording or transcript.

So: almost certainly a real thing a real person said, in roughly these words, somewhere we could not pin down. Which is the honest status of most quotes that travel this way, and worth saying out loud rather than repeating the sentence as though it were sourced.

The six parts, checked against the documentation

That last row carries a consequence the card does not mention and which we worked through separately in the piece on the three schedulers: the cloud routine that runs while you sleep cannot see the files on your machine. If your loop writes drafts into a local folder, part six is not where it runs.

Four honest caveats

1. We did not run a loop. Everything here is the card checked against the /goal, scheduled-tasks and subagent documentation in October 2026.
2. “Cannot see the work” is precise, not rhetorical. The evaluator cannot call tools. But a well-written turn puts the work in the transcript, and then the evaluator genuinely can read it. The constraint is on the condition you write, not on the idea.
3. The quote is unresolved, not debunked. We found consistent attribution and inconsistent wording, and no primary. We are reporting that state, not disputing that he said it.
4. This card is unusually good. Five of six commands check out, the named pattern is named correctly, and the fine print says scores are examples rather than guarantees. The criticism here is of one example prompt, not of the method.

The one-line version

The card is right that the score is the off-switch — and the score is awarded by the cheapest model in the stack, reading a transcript, unable to open the file; so write conditions that the transcript can prove, make the judge show its reasons, and put a turn limit on the end before you schedule it to run while you sleep.

Three edits to one prompt: /goal Score it on my rubric with reasons for each criterion, don’t stop until 95, or stop after 20 turns.